Might be slightly clearer to have these members as pointers and then initialize the objects in the constructor, but I'm not married to having it that way.

You mean, I should do dynamic memory allocation on a microcontroller? I am not a fan of that...

It's a one-time allocation at startup, so that's pretty safe, but if you'd rather not, it can stay as-is. Another possibility would be adding do-nothing constructors to the classes so that they can be initialized empty and the reinitialized afterward.

I prefer the do-nothing constructor path. But I don't get why you want to initialize the class later? In the setup()
function to avoid the init() method?

All I'm suggesting is having the option for the example to look like this, which feels a bit more like idiomatic roscpp:

  Blinker(byte pin, uint16_t period) : pin_(pin), period_(period)
  {
    subscriber_ = ros::Subscriber("set_blink_period", &Blinker::set_period_callback, this),
    service_server_ = ros::ServiceServer("activate_blinker", &Blinker::service_callback, this)
  }

  void init(ros::NodeHandle& nh)
  {
    pinMode(pin_, OUTPUT);

    nh.subscribe(subscriber_);
    nh.advertiseService(service_server_);
  }

However, it's not going to work regardless without also re-specifying all the template arguments since there's no type inference on constructors, so that kind of blows it away anyway (and there'd need to be copy constructors added). So I think the best thing is to merge this contribution as-is, and if there's interest now or later in streamlining or adding to the API, that can be discussed on separate PR.